Effective Java 2.0_中文版_Item 6

| |
Effective Java 2.0_中文版_Item 6

文章作者：Tyan
博客：noahsnail.com | CSDN | 简书

Item 6: 消除废弃的对象引用

当你从一个手动管理内存的语言（例如C或C++）转到一个具有垃圾回收机制的语言时，作为一个程序员你的工作会更容易，当你使用完对象时，它们会被自动回收。当你第一个经历它时，它简直不可思议。它很容易给你留下一个你不需要考虑内存管理的印象，但事实并非如此。

考虑下面一种简单的栈实现的情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Can you spot the "memory leak"?
public class Stack {
	private Object[] elements;
	private int size = 0;
	private static final int DEFAULT_INITIAL_CAPACITY = 16;

	public Stack() {
		elements = new Object[DEFAULT_INITIAL_CAPACITY];
	}

	public void push(Object e) {
		ensureCapacity();
		elements[size++] = e;
	}

	public Object pop() {
		if (size == 0)
			throw new EmptyStackException();
		return elements[--size];
	}

	/**
	 * Ensure space for at least one more element, roughly doubling the capacity
	 * each time the array needs to grow.
	 */
	private void ensureCapacity() {
		if (elements.length == size)
			elements = Arrays.copyOf(elements, 2 * size + 1);
	}
}

这个程序没有明显的错误（但请看Item 26的泛型版本）。你可以对它进行全面测试，它能出色的通过每一次测试，但这儿有一个潜在的问题。不严格的说，这个程序有一个『内存泄露』问题，由于垃圾回收活动的增加或内存占用的增加，性能下降的情况会逐渐表现出来。在极端的情况下，这种内存泄露可能引起磁盘分页，甚至会引起程序失败（OutOfMemoryError），但这种失败是相对稀少的。

内存泄露在哪呢？如果栈先增长后收缩，出栈的对象将不能作为垃圾被收回，即使使用栈的程序不再引用它们。这是因为栈维护着这些对象的废弃引用。废弃引用是永远不会再解引用的引用。在这种情况下，元素数组活跃部分之外的其它引用都将被废弃。活跃部分包含了那些索引小于size的元素。

内存泄露在垃圾回收语言是隐蔽的（更合适的称呼是无意识对象保持）。如果一个对象引用被无意保留，不仅这个对象不能被垃圾回收处理，而且这个对象引用的其它对象也不能被垃圾回收处理，以此类推。即使只无意保留了几个对象的引用，但可能阻止了垃圾回收机制回收许多其它的对象，在性能上会有很大的潜在影响

这类问题的修正很简单：一旦对象引用过期，就清空这些引用。在我们的Stack类例子中，只要某一项从栈中取出，它的引用就过时了。pop方法的修正版本如下：

1
2
3
4
5
6
public Object pop() {
	if (size == 0)
		throw new EmptyStackException();
	Object result = elements[--size];
	elements[size] = null; // Eliminate obsolete reference return result;
}

清空废弃引用的一个额外收益是，如果它们接下来被误解引用，程序会立刻报出NullPointerException，而不是静静地做错误的事情。对于尽可能快的检测程序错误，它总是有益的。

当程序员第一次被这个问题困扰时，他们可能是过分小心了，程序一旦完成了对象的使用，就清空每一个对象的引用。这既没必要也不可取，因此它会将程序不必要的弄乱。清空对象引用应该是例外情况而不是正常的行为。消除废弃引用的最好方式是让包含引用的变量结束其作用域。如果你在最紧凑的作用域范围内定义每个变量，这会很自然的发生。

你应该什么时候清空一个引用？Stack类的哪一个方面让它容易受到内存泄露影响？简单的说，它自己管理自己的内存。存储池包含了元素数组中的元素（对象引用单元，不是对象本身）。数组活跃部分的元素（前面定义的）被分配，数组中其余的元素是自由的。垃圾回收器不知道这种情况；对于垃圾回收器而言，元素数组中的所有对象引用都同等有效。只有程序员知道数组中非活跃部分是不重要的。程序员通过手动清空数组元素中不活跃的部分，可以有效的告诉垃圾回收器这个事实。

一般来说，只要一个类自己管理自己的内存，程序员就应该警惕内存泄露。无论什么时候释放一个元素，这个元素包含的对象引用都应该被清空。

另一个常见的内存泄露来源是缓存。一旦你把一个对象引用放入缓存，很容易忘了它在缓存中，在用完之后很长一段时间仍把它放在缓存中。这个问题有几种解决方案。如果你很幸运的要实现一个对于输入项的缓存，只要缓存外部有输入项的键的引用，它就是相对确定的，可以用一个WeakHashMap来表示缓存；在输入项废弃之后，它们会被自动移除。记住，只有缓存输入项的生命周期由输入项键的外部引用决定，不是由输入项值的外部引用决定时，WeakHashMap才有用的。

第三个常见的内存泄露来源是监听器和其它的回调函数。如果你实现一个API，它的客户端注册了回调函数但没有显式的注销它们，除非你采取一些动作，否则它们将累积。确保回调函数可以迅速被垃圾回收的最好方式是为存储它们的弱引用，例如，只将它们保存为WeakHashMap的键。

因为通常内存泄露没有明白的失败来揭露它们，它们可能在系统中存在许多年。通常只有通过小心的代码检查或通过调试工具（通常被称为堆分析器）的帮助才能发现它们。因此，在它们发生和阻止它们发生之前，就学习预测这种问题是很有必要的。

如果有收获，可以请我喝杯咖啡！